home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1680 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.8 KB
  1. Path: news.th-darmstadt.de!news
  2. From: Enno Sandner <enno@intellektik.informatik.th-darmstadt.de>
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: IsA v/s HasA problem
  5. Date: Fri, 12 Jan 1996 09:18:47 +0100
  6. Organization: Fachbereich Informatik, TH Darmstadt
  7. Message-ID: <30F61967.167EB0E7@intellektik.informatik.th-darmstadt.de>
  8. References: <30F52C66.851@bangate.compaq.com>
  9. NNTP-Posting-Host: kitz.intellektik.informatik.th-darmstadt.de
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0b4 (X11; I; SunOS 4.1.3 sun4m)
  14.  
  15. Saurabh Dixit wrote:
  16. > 
  17. > Hi!
  18. > 
  19. > I always had no trouble distinguishing between the two...
  20. > 
  21. > But now, I for a specific case, I fail to see the repercussions of
  22. > using the wrong relationship between objects.
  23. > 
  24. > This is my scenario.
  25. > I have an object of type Base.  This is an abstract class.
  26. > From Base I derive several different objects.
  27. > I want to maintain a list of such objects for which I have a class
  28. > Collection that encapsulates a typed array of Base objects.
  29. > 
  30. > I now want to define an object - let's call it Duh - that maintains a
  31. > collection of Base objects.  Duh objects are entities on their own and could
  32. > have other attributes, BUT NEVER ANOTHER COLLECTION.
  33. > 
  34. > From what I gather, I am then leaning towards a HasA relationship, i.e.
  35. > class Collection
  36. > {
  37. > public:
  38. >         BOOL Add (Base* b);
  39. > };
  40. > class Duh
  41. > {
  42. > private:
  43. >         Collection c;
  44. > };
  45. > 
  46. > Obviously if I was going to have 2 or more collections, then I would have had
  47. > to have a HasA relationship.  But as said earlier, this is not the case!
  48. > Also, I want to have some operations common between Collection and Duh.
  49. > e.g. I can Add() a Base (derived!) object to a Collection and I also want
  50. > to Add() an object to Duh.  In a HasA relationship I would simply
  51. > implemenent this as follows.
  52. > BOOL Duh::Add (Base* b)
  53. > {
  54. >         // simply pass on to Collection method
  55. >         return c.Add (b);
  56. > }
  57. > However for an IsA relationship, I would simply do
  58. > class Duh : public Collection
  59. > {
  60. > };
  61. > and I am done.
  62. > 
  63. > Am I wasting my time too much thinking about this?  Regardless of code
  64. > implementation, from the logical perspective, what is the correct object-
  65. > oriented solution for my problem, HasA or IsA?
  66. > 
  67.  
  68. The first thing you should think about, if you are planning to let 'Duh'
  69. and 'Collection' form an ISA relationsship:
  70.  
  71.    is it reasonable to regard 'Duh' as specialization of a 'Collection'
  72.    or do you just 'borrow' the functionality.
  73.  
  74. For example you should not
  75. o narrow the interface
  76. o redefine functions in way that violates the assumptions made in the
  77.   Collection class.
  78.     
  79. If 'Duh' is planned to be a collection with some additional behavior it's
  80. reasonable to derive it public from 'Collection'.
  81. Otherwise the HasA relationsship seems to be the better choice.
  82.  
  83.     Enno
  84.